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Abstract 


One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based 
Service Discovery (DNS-SD) was to retire AppleTalk and the AppleTalk 
Name Binding Protocol (NBP) and to replace them with an IP-based 
solution. This document presents a brief overview of the 
capabilities of AppleTalk NBP and outlines the properties required of 
an IP-based replacement. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6760. 
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1. Introduction 


An important goal of the participants working on Zeroconf, Multicast 
DNS, and DNS-Based Service Discovery was to provide a viable IP-based 
replacement for AppleTalk and the AppleTalk Name Binding Protocol 
(NBP). 


There are many who are experts in the Domain Name System (DNS) who 
know nothing about the AppleTalk Name Binding Protocol (NBP). 

Without some background on how AppleTalk and NBP worked, it may be 
difficult to understand the reasoning and motivations that led to the 
design decisions in Multicast DNS and DNS-Based Service Discovery. 


This document seeks to remedy this problem by clearly stating the 
requirements for an IP-based replacement for AppleTalk and NBP. 
Replacing NBP was not the sole goal of Multicast DNS; therefore, 


these requirements are not the sole design considerations. However, 
replacing NBP was a major motivation behind the work in Multicast 
DNS. 


In most cases, the requirements presented in this document are simply 
a restatement of what AppleTalk NBP currently does. However, this 
document is not restricted to describing only what NBP currently 
does. Achieving at least equivalent functionality to NBP is a 
necessary but not sufficient condition for a viable replacement. In 
some cases, the requirements for a viable IP-based replacement go 
beyond NBP. For example, AppleTalk NBP uses Apple Extended ASCII for 
its character set. It is clear that an IP-based replacement being 
designed today should use Unicode, in the form of UTF-8 [RFC3629]. 
AppleTalk NBP has a reputation, partially deserved, for being too 
chatty’ on the network. An IP-based replacement should not have 
this same failing. The intent is to learn from NBP and build a 
superset of its functionality, not to replicate it precisely with all 
the same flaws. 


The protocols specified in "Multicast DNS" [RFC6762] and "DNS-Based 
Service Discovery" [RFC6763], taken together, describe a solution 
that meets these requirements. This document is written, in part, in 
response to requests for more background information explaining the 
rationale behind the design of those protocols. 
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2 


Zero Configuration Networking 


Historically, TCP/IP networking required configuration, either in the 
form of manual configuration by a human operator or in the form of 
automated configuration provided by a DHCP server [RFC2131]. 


One of the characteristics of AppleTalk was that it could operate 
without any dependency on manual configuration or a network service 
to provide automated configuration. An AppleTalk network could be as 
small as just two laptop computers connected via an Ethernet cable 
(or wirelessly). 


IP now has self-assigned link-local addresses [RFC3927] [RFC4862], 
which enable IP-based networking in the absence of external 
configuration. What remains is the need for Zero Configuration name- 
to-address translation and Zero Configuration service discovery, both 
capabilities that AppleTalk NBP offered. 


It is not necessarily the case that Zero Configuration Networking 
protocols will always be used in all three areas (addressing, naming, 
and service discovery) simultaneously on any given network. For 
example, even on networks with a DHCP server to provide address 
configuration, users may still use Zero Configuration protocols for 
name-to-address translation and service discovery. Indeed, on a 
single network, users may use conventional Unicast DNS for looking up 
the addresses of Internet web sites while at the same time using 
Multicast DNS for looking up the addresses of peers on the local 
link. Therefore, Zero Configuration Networking protocols must 
coexist peacefully with conventional configured IP networking when 
used together on the same network. 


Networks change state over time. Hosts and services may come and go. 
Connectivity, addresses, and names change. In a manually configured 
network, a human operator can remedy errors when they arise. Ina 
Zero Configuration Network, no such human operator is available to 
diagnose and troubleshoot problems, so Zero Configuration protocols 
need to be self-correcting, automatically accommodating changing 
network conditions, continually converging to correctness in the 
absence of human intervention to manually rectify errors. 


Requirements 


This section lists the 15 requirements for an IP-based replacement 
for AppleTalk NBP. 
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3.1. Name-to-Address Mapping 
NBP’s primary function is translating names to addresses. 


NBP stands for Name Binding Protocol, not Network Browsing Protocol. 
Many people know NBP only as "that thing that used to let you browse 
the network in the old Macintosh Chooser". While browsing is an 
important facility of NBP, it is secondary to NBP’s primary function 
of translating names to addresses. 


Every time a user prints using AppleTalk, the printing software takes 
the name of the currently selected printer, looks up the current 
AppleTalk address associated with that named service, and establishes 
a connection to that service on the network. The user may invoke 
NBP’s browsing capability once, when first selecting the desired 
printer in the Chooser, but after that, every time something is 
printed, it is a simple efficient name-to-address lookup that is 
being performed, not a full-fledged browsing operation. 


Any NBP replacement needs to support, as its primary function, an 
efficient name-to-address lookup operation. 


3.2. Name Services, Not Hardware 


The primary named entities in NBP are services, not "hosts", 
"machines", "devices", or pieces of hardware of any kind. This 
concept is more subtle than it may seem at first, so it bears some 
discussion. 


The AppleTalk NBP philosophy is that naming a piece of hardware on 
the network is of little use if you can’t communicate with that piece 


of hardware. To communicate with a piece of hardware, there needs to 
be a piece of software running on that hardware that sends and 
receives network packets conforming to some specific protocol. This 


means that whenever you communicate with a machine, you are really 
communicating with some piece of software on that machine. Even if 
you just ’ping’ a machine to see if it is responding, it is not 
really the machine that you are /’/pinging’, it is the software on that 
machine that generates ICMP Echo Responses [RFC792]. 


Consequently, this means that the only things worth naming are the 
software entities with which you can communicate. A user who wants 
to use a print server or a file server needn’t care about what 
hardware implements those services. There may be a single machine 
hosting both services, or there may be two separate machines. The 
end user doesn’t need to care. 
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The one exception to this is network managers, who may want to name 
physical hardware for the purpose of tracking physical inventory. 
However, even this can be recast into a service-oriented view of the 
world by saying that what you’re naming is not the hardware, but the 
ICMP Echo Responder that runs (or is assumed to be running) on every 
piece of IP hardware. 


3.3. Address Services, Not Hardware -- or -- Escape the Tyranny of 
Well-Known Ports 


The reader may argue that DNS already supports the philosophy of 
naming services instead of hosts. When we see names like 
"www.example.com.", "pop.example.com.", "smtp.example.com.", 
"news.example.com.", and "time.example.com.", we do not assume that 
those names necessarily refer to different hosts. They are clearly 
intended to be logical service names and could, in fact, all resolve 
to the same IP address. 


The shortcoming here is that although the names are clearly logical 
service names, the result today of doing a conventional ("A" or 
"AAAA") DNS lookup for those names gives you only the IP address of 
the hardware where the service is located. To communicate with the 
desired service, you also need to know the port number at which the 
service can be reached, not just the IP address. 


This means that the port number has to be communicated out-of-band, 
in some other way. One way is for the port number to be a specific 
well-known constant for any given protocol. This makes it hard to 
run more than one instance of a service on a single piece of 
hardware. Another way is for the user to explicitly type in the port 
number, for example, "www.example.com.:8080" instead of 
"www.example.com.", but needing to know and type in a port number is 
as ugly and fragile as needing to know and type in an IP address. 


Another aspect of the difficulty of running more than one instance of 
a service on a single piece of hardware is that it forces application 
programmers to write their own demultiplexing capability. AppleTalk 
did not suffer this limitation. If an AppleTalk print server offered 
three print queues, each print queue ran as its own independent 
service, listening on its own port number (called a socket number in 
AppleTalk terminology), each advertised as a separate, independently 
named NBP entity. When a client looks up the address of that named 
NBP entity, the reply encodes not only on which net and subnet the 
service resides, and on which host on that subnet (like an IP address 
does), but also on which socket number (port number) within that 
host. In contrast, if an lpr print server offers three print queues, 
all three print queues are typically reached through the same well- 
known port number (515), and then the lpr protocol has to use its own 
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demultiplexing capability (the print queue name) in order to 
determine which print queue is sought. This makes it especially 
difficult to run two different pieces of print queue software from 
different vendors on the same machine, because they cannot both 
listen on the same well-known port. 


A similar trick is used in HTTP 1.1, where the "Host" header line is 
used to allow multiple logical HTTP services to run at the same IP 
address. Again, this works for a single-vendor solution, but if a 
user wishes to run multiple web servers (for example, an image 
server, a database program, an HTTP email access gateway, anda 
conventional HTTP server) on a single machine, they can’t all listen 
on TCP port 80, the traditional HTTP port. 


Yet another problem of well-known ports is that port numbers are a 
finite resource. Originally, port numbers 0-255 were reserved for 
well-known services, and the remaining 99.6% of the port space was 
free for dynamic allocation [RFC1122]. Since then, the range of 
"Registered Ports" has crept upwards until today, ports 0-49151 are 
reserved, and only 25% of the space remains available for dynamic 
allocation. Even though 65535 may seem like a lot of available port 
numbers, with the pace of software development today, if every new 
protocol gets its own private port number, we will eventually run 
out. To avoid having to do application-level demultiplexing, 
protocols like the X Window System wisely use a range of port 
numbers, and let TCP do the demultiplexing for them. The X Window 
System uses 64 ports, in the range 6000-6063. If every new protocol 
were to get its own chunk of 64 ports, we would run out even faster. 


Any NBP replacement needs to provide, not just the network number, 
subnet number, and host number within that subnet (i.e., the IP 
address) but also the port number within that host where the service 
is located. Furthermore, since many existing IP services such as lpr 
*do* already use additional application-layer demultiplexing 
information such as a print queue name, an NBP replacement needs to 
support this too by including this information as part of the 
complete package of addressing information provided to the client to 
enable it to use the service. The NBP replacement needs to name 
individual print queues as first-class entities in their own right. 
It is not sufficient merely to name a print server, within which 
separate print queues can then be found by some other mechanism. 


One possible answer here is that an IP-based NBP replacement could 
use a solution derived from DNS SRV records instead of "A" records, 
since SRV records *do* provide a port number. However, this alone is 
not a complete solution, because SRV records cannot tell you an lpr 
print queue name. 
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3.4. Typed Name Space 
AppleTalk NBP names are structured names, generally written as: 
Name : Type @ Zone 
Name: The Name is the user-visible name of the service. 


Type: The Type is an opaque identifier that identifies the service 
protocol and semantics. The user may think of the Type as 
identifying the end-user function that the device performs (e.g., 
"printing"), and for the typical end-user, this may be an adequate 
mental model, but strictly speaking, from a protocol-design 
perspective, the Type identifies the semantic application protocol 
the service speaks: no more, no less. For convenience, the opaque 
Type identifier is generally constructed using descriptive ASCII 
text, but this text has no meaning to the protocol, and care should 
be taken in inferring too much meaning from it. For example, the NBP 
Service Type "LaserWriter" means "any service that speaks 
PS/PAP/ATP/DDP (PostScript over AppleTalk Printer Access Protocol 
over AppleTalk Transaction Protocol over AppleTalk Datagram Delivery 
Protocol)". It does not necessarily mean an Apple-branded 
"LaserWriter" printer; nor does the service even have to be a 
printer. A device that archives documents to digital media could 
advertise itself as a "LaserWriter", meaning that it speaks 
PostScript over PAP, not necessarily that it prints that document on 
paper when it gets it. The end-user never directly sees the Service 
Type. It is implicit in the user’s action; for example, when 
printing, the printing software knows what protocol(s) it speaks and 
consequently what Service Type(s) it should be looking for -- the 
user doesn’t have to tell it. 


Zone: The Zone is an organizational or geographical grouping of named 
services. AppleTalk Zones were typically given names like 
"Engineering", "Sales", or "Building 1, 3rd floor, North". The 
equivalent concept in DNS could be a subdomain such as 
"Engineering.example.com.", "Sales.example.com.", or "Building 1, 3rd 
floor, North.example.com." 


Each {Type,Zone} pair defines a name space in which service names can 
be registered. It is not a name conflict to have a printer called 
"Sales" and a file server called "Sales", because one is 
"Sales:LaserWriter@Zone" and the other is "Sales:AFPServer@Zone". 


Any NBP replacement needs to provide a mechanism that allows names to 
be grouped into organizational or geographical "zones", and within 
each "zone", to provide an independent name space for each service 
type. 
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3.5. User-Friendly Names 


When repeatedly typing in names on command-line systems, it is 
helpful to have names that are short, all lowercase, without spaces 
or hard-to-type characters. 


Since Service Names are intended to be selected from a list, not 
repeatedly typed in on a keyboard, there is no reason for them to be 
restricted so. Users should be able to give their printers names 
like "Sales", "Marketing", and "3rd Floor Copy Room", not just 
"printerl.example.com.". Of course, a user is free to name a 
particular service using only lowercase letters and no spaces if they 
wish, but they should not be forced to do that. 


Any NBP replacement needs to support a full range of rich text 
characters, including uppercase, lowercase, spaces, accented 
characters, and so on. The correct solution is likely to be UTF-8 
Unicode [RFC3629]. 


Note that this requirement for user-friendly rich-text names applies 
equally to the zones (domains) in which services are registered and 
discovered. 


Note that although the characters ’:’ and ’@’ are used when writing 
AppleTalk NBP names, they are simply a notational convenience in 


written text. In the on-the-wire protocol and in the software data 
structures, NBP Name, Type, and Zone strings are all allowed to 
contain almost any character, including ’:’ and ’@’. The naming 


scheme provided by an NBP replacement must allow the use of any 
desired characters in service names, including dots (’.’), spaces, 
percent signs, etc. 


3.6. Zeroconf Operation 


AppleTalk NBP is self-configuring. On a network of just two hosts, 
they communicate peer-to-peer using multicast. On a large managed 
network, AppleTalk routers automatically perform an aggregation 
function, allowing name lookups to be performed via unicast to a 
service running on the router, instead of by flooding the entire 
network with multicast packets to every host. 


Any NBP replacement needs to be able to operate in the absence of 
external network infrastructure. However, this should not be the 
only mode of operation. In larger managed networks, it should also 
be possible to take advantage of appropriate external network 
infrastructure when present, to perform queries via unicast instead 
of multicast. 
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3.7. Name Space Management -- or -- Name Conflict Detection 


Because an NBP replacement needs to operate in a Zeroconf 
environment, it cannot be assumed that a central network 
administrator is managing the network. Unlike managed networks where 
normal administrative controls may apply, in the Zeroconf case an NBP 
replacement must make it easy for users to name their devices as they 
wish, without the inconvenience or expense of having to seek 
permission or pay some organization like a domain name registry for 
the privilege. However, this ease of naming, and freedom to choose 
any desired name, may lead to name conflicts. Two users may 
independently decide to run a personal file server on their laptop 
computers, and (unimaginatively) name it "My Computer". When these 
two users later attend the next IETF meeting and find themselves part 
of the same wireless network, there may be problems. 


Similarly, every Brother network printer may ship from the factory 
with its Service Name set to "Brother Printer". On a typical small 
home network where there is only one printer, this is not a problem; 
however, it could become a problem if two or more such printers are 
connected to the same network. 


Any NBP replacement needs to detect such conflicts, and handle them 
appropriately. In the case of a laptop computer, which has a 
keyboard, screen, and a human user, the software should display a 
message telling the user that they need to select a new name. 


In the case of printers, which typically have no keyboard or screen, 
the software should automatically select a new unique name, perhaps 
by appending an integer to the end of the existing name, e.g., 
"Brother Printer 2". Note that, although this programmatically 
derived name should be recorded persistently for use next time the 
device is powered on, the user is not forced to use that name as the 
long-term name for the service/device. In a network with more than 
one printer, the typical user will assign human-meaningful names to 
those printers, such as "Upstairs Printer" and "Downstairs Printer", 
but the ability to rename the printer using some configuration tool 
(e.g., a web browser) depends on the ability to find the printer and 
connect to it in the first place. Hence, the programmatically 
derived unique name serves a vital bootstrapping role, even if its 
use in that role is temporary. 


Because of the potentially transient nature of connectivity on small 
portable devices that are becoming more and more common (especially 
when used with wireless networks), this name conflict detection needs 
to be an ongoing process. It is not sufficient simply to verify 
uniqueness of names for a few seconds during the boot process and 
then assume that the names will remain unique indefinitely. 
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If the Zeroconf naming mechanism is integrated with the existing 
global DNS naming mechanism, then it would be beneficial for a sub- 
tree of that global namespace to be designated as having only local 
significance, for use without charge by cooperating peers, much as 
portions of the IPv4 address space are already designated as local- 
significance-only, available for organizations to use locally without 
charge as they wish [RFC1918]. 


3.8. Late Binding 


When the user selects their default printer, the software should 
store only the name, not the IP address and port number. Then, every 
time the user prints, the software should look up the name to find 
the current IP address and port number for that service. This allows 
a named logical service to be moved from one piece of hardware to 
another without disrupting the user’s ability to print to that named 
print service. 


On a network using DHCP [RFC2131] or self-assigned link-local 
addresses [RFC3927] [RFC4862], a device’s IP address may change from 
day to day. Deferring binding of name to address until actual use 
allows the client to get the correct IP address at the time the 
service is used. 


Similarly, with a service using a dynamic port number instead of a 
fixed well-known port, the service may not get the same port number 
every time it is started or restarted. By deferring binding of name 
to port number until actual use, the client gets the correct port 
number at the time the service is used. 


3.9. Simplicity 


Any NBP replacement needs to be simple enough that vendors of even a 
low-cost network ink-jet printer can afford to implement it in the 
device’s limited firmware. 


3.10. Network Browsing 


AppleTalk NBP offers certain limited wild-card functionality. For 
example, the service name "=" means "any name". This allows a client 
to perform an NBP lookup such as "=:LaserWriter@My Zone" and receive 
back in response a list of all the PS/PAP (AppleTalk Printer Access 
Protocol) printers in the Zone called "My Zone". 


Any NBP replacement needs to allow a piece of software, such as a 
printing client or a file server client, to enumerate all the named 
instances of services in a specified zone (domain) that speak its 
protocol(s). 
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3.11. Browsing and Registration Guidance 
AppleTalk NBP provides certain meta-information to the client. 


On a network with multiple AppleTalk Zones, the AppleTalk network 
infrastructure informs the client of the list of Zones that are 
available for browsing. It also informs the client of the default 
Zone, which defines the client’s logical "home" location. This is 
the Zone that is selected by default when the Macintosh Chooser is 
opened, and is usually the Zone where the user is most likely to find 
services like printers that are physically nearby, but the user is 
still free to browse any Zone in the offered list that they wish. 


A Brother printer may be pre-configured at the factory with the 
Service Name "Brother Printer", but they do not know on which network 
the printer will eventually be installed, so the printer will have to 
learn this from the network on arrival. On a network with multiple 
AppleTalk Zones, the AppleTalk network infrastructure informs the 
client of a single default Zone within which it may register Service 
Names. In the case of a device with a human user, the AppleTalk 
network infrastructure may also inform the client of a list of Zones 
within which the client may register Service Names, and the user may 
choose to register Service Names in any one of those Zones instead of 
in the suggested default Zone. 


Any NBP replacement needs to provide the following information to the 
client: 


* The suggested zone (domain) in which to register Service Names. 


* A list of recommended available zones (domains) in which Service 
Names may be optionally registered. 


* The suggested default zone (domain) for network browsing. 

* A list of available zones (domains) that may be browsed. 
Note that, because the domains used in this context are intended for 
service browsing in a graphical user interface, they should be 
permitted to be full user-friendly rich text, just like the rest of a 
service name. 

3.12. Power Management Support 

Many modern network devices have the ability to go into a low-power 
mode, where only a small part of the Ethernet hardware remains 


powered, and the device can be woken up by sending a specially 
formatted Ethernet frame that the device’s power-management hardware 
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recognizes. A modern service discovery protocol should provide 
facilities to enable this low-power mode to be used effectively 
without sacrificing network functionality, such as the ability to 
discover services on sleeping devices, and wake up a sleeping device 
when it is needed. 


3.13. Protocol Agnostic 


Fashions come and go in the computer industry, but a service 
discovery protocol, being one of the foundation components on which 
everything else rests, has to be able to outlive these swings of 
fashion. A useful service discovery protocol should be agnostic to 
the protocols being used by the higher-layer software it serves. If 
a service discovery protocol requires all the higher-layer software 
to be written in a new computer language, or requires all the higher- 
layer protocols to embrace some trendy new data representation format 
that is currently in vogue, then that service discovery protocol is 
likely to have limited utility after the fashion changes and computer 
industry moves on to its next infatuation. 


3.14. Distributed Cache Coherency Protocol 


Any modern service discovery protocol must use some kind of caching 
for efficiency. Any time a distributed cache is maintained, a cache 
coherency protocol is required to control the effects of stale data. 
Thus, a useful service discovery protocol needs to include cache 
coherency mechanisms. 


3.15. Immediate and Ongoing Information Presentation 


Many current discovery mechanisms display an hourglass or a "Please 
Wait" message for five or ten seconds, and then present a list of 
results to the user. At this point, the list of results is static, 
and does not update in response to changes in the environment. To 
see current information, the user is forced to click a "Refresh" 
button repeatedly, waiting another five to ten seconds each time. 


Neither limitation is acceptable in a protocol that is to replace 
NBP. When a user initiates a browsing operation, the user interface 


should take at most one second to present the list of results. In 
addition, the list should update in response to changes in the 
environment as they happen. If the user is waiting for a particular 


service to become available, they should be able simply to watch 
until it appears, with no "Refresh" button that they need to keep 
clicking. A protocol to replace AppleTalk NBP must be able to meet 
these requirement for timeliness of information discovery, and 
liveness of information updating, without placing undue burden on the 
network. 
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4. 


Existing Protocols 


Ever since this work began with Stuart Cheshire’s email to the net- 
thinkers@thumper.vmeng.com mailing list in July 1997, the question 
has been asked, "Isn’t SLP the IETF replacement for AppleTalk NBP?" 


The Service Location Protocol (SLP) [RFC2608] provides extremely rich 
and flexible facilities in the area of Requirement 10, "Network 
Browsing". However, SLP provides none of the service naming, 
automatic name conflict detection, or efficient name-to-address 
lookup that form the majority of what AppleTalk NBP does. 


SLP returns results in the form of URLs. In the absence of DNS, URLS 
cannot usefully contain DNS names. Discovering a list of service 
URLs of the form "ipp://169.254.17.202/" is not particularly 
informative to the user. Discovering a list of service URLs of the 
form "ipp://epson-stylus-900n.local./" is slightly less opaque 
(though still not very user-friendly), but to do even this, SLP would 
have to depend on Multicast DNS or something similar to resolve names 
to addresses in the absence of a conventional DNS server. 


SLP provides fine-grained query capabilities, such as the ability to 
prune a long list of printers to show only those that have blue paper 
in the top tray, which could be useful on extremely large networks 
with very many printers, but are certainly unnecessary for a typical 
home or small office with only one or two printers. 


In summary, SLP alone fails to meet most of the requirements, and 
provides vastly more mechanism than necessary in the area of 
Requirement 10. 


IPv6 Considerations 


An IP replacement for the AppleTalk Name Binding Protocol needs to 
support IPv6 as well as IPv4. 


Security Considerations 


The AppleTalk Name Binding Protocol was developed in an era when 
little consideration was given to security issues. In today’s world, 
this would no longer be appropriate. Any modern replacement for 
AppleTalk NBP should have security measures appropriate to the 
environment in which it will be used. Given that this document is a 
broad historical overview of how AppleTalk NBP worked, and does not 
specify any new protocol(s), it is beyond the scope of this document 
to provide detailed discussion of possible network environments, what 
protocols would be appropriate in each, and what security measures 
would be expected of each such protocol. 
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